Requirements TMS 



Accessing the Ticketing system 

TMS will be web-based application publicly hosted. It can be accessed using a device (mobile, tablet, computer) having a browser installed and 
internet access. 

Tickets - Definition and features 

Ticket is manifestation of TASK on the platform. Ticket is the core component of the platform, it provide the means to record information about a 
tasl<. Ticket and task will be used synonymously henceforth. Depending on the type of task (task, sub-task or work request) one or more fields 
will be used. Following are the key attributes of the Ticket: 

1 . Key* - a unique auto-generated code for the ticket to identify or refer it within the system. Key have two parts "department key and id 
number" e.g. FIN-01 represents the first ticket created for Finance department, iT-28 similarly represents 28'^ ticket created for IT 
department. Nomenclature for sub-tasks is pending, for work request key will be like WR-01 , WR-100. 

2. Requestor* — the user who creates or raises the ticket. 

3. Assignee* - the staff who is delegated the ticket for resolution. 

4. Subject* — this is the title of the ticket - a brief description summarizing the task. This input will be taken in plain text without formatting. 
Max length of the subject is 1 00 characters. 

5. Description — the body of the ticket. A good description should be specific, descriptive and to the point. This Input will accept text 
formatting. This is a text field with limit of 5000 characters. 

6. Category — category and sub-category (defined next) is an optional field depending upon assignee department. Currently category and 
sub-category are only defined for IT department. IT ticket can represent anything ranging from a hardware problem or a software problem 
that fits in day-to-day operations of the organization. E.g. Domain A/C, email, printer etc. Category master list can be updated by admin 
at any point of time. 

7. Sub-Category — sub category of the ticket. E.g. For IT ticket Category Email - new email a/c, disable a/c are sub categories. 

Sub-category master list can be updated by admin at any point of time. 

8. Priority* — the importance of the ticket, URGENT, Higti, MEDIUM or LOW. SLA for all the tickets will be same. 

9. Status* — current status of tasks - Draft (save), In-review (submitted), HOD Approved, HOD Rejected, AD-HOD approved, AD-HOD 
reject. Management Approved, Management Rejected, WIP (work in progress). On Hold (task is accepted by the staff but kept on hold for 
some time, staff can resume working on ticket by changing status to WIP manually), Re-Submit (re-open the Issue), Completed, Closed, 
Cancelled. 

10. Resolution Status -Unresolved, Fixed (the only resolution status for successful resolution of ticket). Duplicate, Insufficient Info, Not 
Replicable. This is a compulsory field to be populated by staff/asginee when "resolving" a ticket, by default value of ticket is "Unresovled" 

11. Co & Bcc — a comma-separated list of other users or E-Mail addresses to notify. Note That This Will Not Impiy Responsibility Or Any 
Other Policy. Staff will populate these fields manually and will email to cc or bcc list details of the task according to her requirement. 

12. Labels — Labels are a convenient way to group or identify the tickets. It Is a very useful tool for searching and report generation. A label 
is a non-hierarchical metadata which help a user identify an item. Most common example on web (especially social media) is hashtag. 
Just imagine an event of office relocation, all IT taks corresponding to the relocation can be "Labeled" under one label e.g. "singapore_offi 
ce_reiocation" , identifying a group of tickets, with multiple tags, related to specific issue which can help ITEs resolve similar issues in 
future e.g. "firewall-rules" & "dos-attack" 

13. Resolutions Summary - Summary regarding resolution of the ticket. 

14. Resolutions Date - Actual resolution date of the issue. 

15. Date Due* - date by which ticket has to be resolved. Automatically calculated and populated by system as per the SLA period defined. 
SLA will be dependent on the level of the SR, and can be changed by the admin. 

1 6. Date Created* - Date the ticket was created. 

1 7. Date Updated*- The date ticket was last modified. When ticket is created this field is same as date created. 

18. Modified By* - The user who last modified the record. 

19. Attachments - Provision to attach the documents relevant for Ticket Resolving 

Ticket Workflow 

1 . Employee creates a ticket against a department called Assignee Department (AD). Without submitting she can save the ticket. The 
status of ticket is "Draft" before it is submitted, status = "draft" 

2. Employee submits the ticket. Before submitting the ticket employee has to selects the department against which ticket is created. Status 
= "in-review" 

3. System automatically set the assignee to the HOD. 



4. Ticket can be re-called while status is "in-review", ticket will go back to "draft" mode and user can make changes to issue and also delete 
the ticket. Deleted ticket will not be re-usable but history of this ticket will be saved. 

5. HOD takes one of following action on the Ticket 

a. Approves: HOD approval can have two scenarios. In both cases the final status = "HOD approved" 

i. Single Department Ticket: HOD feels that ticket can be completed by the AD alone and simply approves the tickets. Go 
to 6. 

11. Multi Department Ticket: HOD feels the ticket cannot be completed by the AD alone and adds more departments and 
them approves. Note: additional departments have to be added before approval. Go to 8 

b. Rejects: HOD adds the reason for reject, system assigns the ticket back to Employee and ticket is dead i.e. no further action can 
be taken on ticket. Status: "HOD reject" 

6. System assigns the ticket to HOD of AD. 

7. AD HOD takes action on the tickets: 

a. Approves: AD HOD manually assigns the ticket to one of the staff and approves the ticket. Status: "AD HOD approved" 

i. Staff starts working on the ticket, she can do following 

1 . Start working on the ticket, status: "WIP" 

2. Create Work Requests (WR); this is an optional step which staff might take. While the ticket status is "WIP" staff 
creates one or more WR for any department. Staff might change the status of ticket to "on hold" if he wants and 
once the WR(s) are completed he will resume it to "WIP". 

3. Resolves the issue, she will update the ticket with steps taken to resolve, this information will be captured in 
"resolution summary" field of Ticket. She will also update the ticket with appropriate "resolution status". Status: 
"resolved" 

4. System assigns the ticket back to AD HOD. 

ii. AD HOD takes action 

1 . If satisfied she assigns ticket to HOD. 

2. If not satisfied she will re-open the ticket and assign it back to staff, staff will start working again i.e. repeat from 
9.A.i.a. Status: "re-submit" 

ill. HOD takes action. 

1 . If HOD is satisfied he closes down the ticket, go to last step. Status: "closed" 

2. If not Re-open the ticket and assigns it back to AD-HOD, go to 7.A. Status: "re-submit" 

b. Rejects: AD HOD adds the reason for reject, system assigns the ticket back to HOD and ticket is dead i.e. no further action can 
be taken on ticket. Status: "AD HOD reject" 

8. System assigns the ticket to HOD of each AD 

9. Each AD HOD takes action on the tickets: 

a. Approves: AD HOD assigns the ticket to one of the staff and approves the ticket. Status: "AD HOD approved" 

i. Staff starts working on the ticket, she can do following. 

1 . Start working on the ticket, status: "WIP" 

2. Create Work Requests (WR), this is an optional step which staff might take. While the ticket status is "WIP" staff 
creates one or more WR for any department. Staff might change the status of ticket to "on hold" if he wants and 
once the WR(s) are completed he will resume it to "WIP". 

3. Resolves the Issue, she will update the ticket with steps taken to resolve, this Information will be captured in 
"resolution summary" field of Ticket. She will also update the SR with appropriate "resolution status". Status: 
"resolved" 

4. System assigns the ticket back to AD HOD. 
II. AD HOD takes action 

1 . If satisfied she assigns department ticket back to HOD. 

2. If not satisfied she will re-open the ticket and assign back to staff, staff will start working again i.e. repeat from 
9.A.i.a. Status: "re-submit" 

ill. Once a department tickets is closed, HOD takes action. 

1 . If HOD is satisfied he closes down the department ticket. Status: "closed" 

2. If not Re-open the department ticket and assigns it back to AD-HOD. Status: "re-submit" 

iv. Once all department tickets are closed, HOD closes down the main ticket go to last step. Status: "closed" 

b. Rejects: AD HOD adds the reason for reject, system assigns the ticket back to HOD and ticket is dead I.e. no further action can 
be taken on ticket. Status: "AD HOD reject" 

1 0. Last Step. Ticket End of life. 

Work Request workflow 

1 . A WR is create by an employee of a department and assigned it to another employee. Status: "submit" 

2. Assignee take action: 

a. If accepted by the assignee Status: "accept" 



b. If reject status: Status: "reject" 
3. Once accepted assignee completes the tasks and provides the resolution to creator. 

Points to note 

1 . Employee can belong to any department and can raise ticket against any department including her own department 

2. In case the employee creates ticket to be resolved within his department, HOD approval will take care of AD HOD approval also i.e. only 
HOD approval is required no AD HOD approval because both HODs are same in this case. 

3. Tickets created by HOD and Management are self-approved - think about this in detail 

4. Work Request are created to execute small tasks and do not require approval like tickets. It has only three status submit, accept and 
reject 

5. Each department will have pre-assigned project, under which the tickets of that department will be added e.g. Finance, IT, Procurement 
etc. 

User Profiles 

Each user will have a defined name and will belong to a department in a region. To tie the current user to their role within the organization and for 
unique identification, email addresses and/or a username will be used. This allows flexibility when deciding on the authentication mechanism and 
also allows for an authorization scheme that can determine who the person is that has logged on and which application areas does she has 
access to. Key attributes for the user profiles are as follows: 

1 . User id* - A system generated unique code to identify or refer a user 

2. First Name* - First name of the User 

3. Last Name* - Last Name of the User 

4. Username* - The username of this user. Used to link login to person's details 

5. User Role* - The role the user is given on the ticketing platform 

6. EmaiH * - Company email id if of the user. 

7. Email2- private email id address of the user. 

8. Contact Number* - Contact Number of the user 

9. Mobile number - Handset number of the user 

1 0. Address - Address of the user 

1 1 . Country - Country the User belongs to 

1 2. City - City the user belongs to 

1 3. Department - The Department user belongs to 

1 4. Designation - Designation of the user 

15. Tag/Group - Tags are a convenient way to group or identify the random set of users. Useful for searching and report generation. This is 
different from hierarchical and organized groups like departments. E.g. Voluntary IT represented from each department can be grouped 
under one Tag called " IT Representative" 

1 6. Date Created- Date the record was created 

1 7. Created By - The user who created the record 

1 8. Date l\^odified - The date the record was last modified 

19. Modified By - The user who last modified the record 

20. Reporting To/Manager - person to whom user reports directly 

21 . Status - is the account active or not 

* Compulsory fields 

User Roles 

User Roles are the roles users accessing ITS will be given. Based on the roles allotted, the user will have access to various functionalities of the 
platform in order to be able to raise, manage and resolve the SRs. 

1 . Employee - Users assigned this role can perform following activities 

a. Save, submit or recall a SR, view details of existing SRs created by her, provide feedback on resolved SRs 

b. Update her profile page 

2. Manager (HOD) - Users assigned this role can perform following activities 

a. Approve or reject the tickets created by her subordinates 

b. View the status of tickets belonging to her department 

c. Update her profile page 

3. IT Manager - Users assigned this role can perform following activities 



a. Approve or reject the SR approved by HODs 

b. Assign manually the SR to an ITE or let system take care of It 

c. Monitoring the status of the ticl<ets raised 

d. Create meeting requests for an SR via email 

e. Escalate an SR - change level or re-assign it to a new ITE 

f. Add or remove tags to SR 

g. Update her profile page 

4. System Administrator -User assigned this role will execute some tasks for IT Manager. 

a. IT Manager will delegate repetitive and/or less important tasks to system administrator. 

b. Sys-admin is responsible for key issues like SR escalation, SR assigning or re-assigning, SR level change etc. 

c. Update her profile page 

d. Add or remove tags to SR 

5. Administrator - Users assigned this role can perform following activities 

a. Add or remove users, locations, departments, categories, sub-categories, levels to the platform 

b. Add or remove user access to applications (ITS, IMS, Audit System etc.) 

c. Add, remove or change the user role, details of a user 

d. Modify the SLA period 

e. Add or remove tags to SR 

f. Add or remove tags to Users 

g. Update her profile page 

6. Support Engineer - User assigned this role will be responsible for handling level-1 support request. Users assigned this role can 
perform following activities 

a. View and accept SR from her IT pool 

b. Edit fields of the assigned the SR 

c. Email the details of the ticket to registered 

d. Create meeting requests for an SR via email 

e. Resolve ticket, add resolution summary 

f. Escalate a SR 

g. Update her profile page 

h. Add or remove tags to SR 

7. Network Engineer - User assigned this role will be responsible for handling level-2 support request. Users assigned this role can 
perform same tasks as Support Engineer. 



